書籍 SRE
https://gyazo.com/d477f61c1be48fa980fb0fb1186f29f7
1章 イントロダクション
SREの信条
以下に責任を負う
サービスの可用性
レイテンシ
パフォーマンス
効率性
変更管理
漸進的なロールアウトの実装
高速かつ正確な問題の検出
モニタリング
アラート
チケット
ロギング
緊急対応
キャパシティプランニング
需要を予測して適切なキャパシティと冗長性を確保する
普段の運用作業を50%におさえる
コーディングの時間を確保するため
100%の信頼性を目標とすることは、基本的にいかなる場合にも間違っている
例外もある。ペースメーカとか
銀行のATMもかなmizukmb.icon
プロダクトの利用方法を踏まえて、可用性のレベルを考える
可用性に満足できないユーザに対する代替案
可用性の変更でプロダクトの利用の仕方に何が起こるか
利用できない時間をバジェット(予算)として確保する
超過しなければ、基本的に何にでも使える
機能のリリース速度を最大化することを目的としている
SREはサービス障害をゼロにすることではないということがわかる
GoogleのSREはソフトウェアエンジニアのスキル+UNIXシステム内部とネットワーキング(L1~3あたり)の専門知識を求めている 2章 Googleのプロダクション環境
すごいmizukmb.icon
3章 リスクの受容
定めた以上の可用性を大幅に超えようとしない
それにかかるコストやメリットの損失が大きいため
100%を目指そうとするほどコストが増えていく
可用性の計算は時間以外でも計測可能
Googleだったらリクエスト数を使ってる
$ 可用性 = \frac{成功したリクエスト数}{総リクエスト数}
エラーバジェットは、開発とリリース速度を価値とするソフトウェアエンジニアとの協調のために設けられた？mizukmb.icon
SREとしては、サービスの信頼性を価値とするので、変更を好まない
テストの事が書いてあるけど、SREはアプリケーションコードの動作の信頼性も見るものなの？mizukmb.icon
ソフトウェアエンジニア→SREなので、テストも気にするのはわかるけど…mizukmb.icon
4章 サービスレベル目標
SLI サービスレベル指標
リクエストのレイテンシ
エラー率
システムスループット
可用性
SLO
objectives
SLA
agreements
違反したら何かしらのペナルティ的なのがある
そういうのがない場合は SLO になる
ユーザと暗黙の契約がある、みたいな
計測方法の紹介
インターバル
対象領域
頻度
データ取得方法
など
5章 トイルの撲滅
つまらない作業でも、長期的な価値があれば、それはトイルではない
トイルの度合いの高い作業
手作業であること
繰り返されること
自動化できること
戦術的であること
長期的な価値を持たないこと
サービスの成長に対して O(n) であること
エンジニアリングの時間を確保したいため
確認しないままだと、どんどんトイルの比率は上がっていく
こいつはトイルだな、みたいな棚卸しが必要？mizukmb.icon
トイルで一番多いのは割り込み作業 (問い合わせ対応とか)、次点でオンコール対応、その次にリリースやデプロイ作業
トイルはある程度仕方無いと割り切るぐらいが良い
トイルの割合が多過ぎると、エンジニアリングの時間が減り、SREとしての信頼が揺らいでしまう、いい話mizukmb.icon
18章 SREにおけるソフトウェアエンジニアリング
プロダクション環境を動作させ続けるためのツール開発という領域に取り組む
想定されるユーザはSREの同僚になる